Skip to content

feat: Add --allow-invalid-content-type-endpoint option to validate-json - #932

Merged
DannyvdSluijs merged 3 commits into
jsonrainbow:mainfrom
zoliszabo:feature/env-for-invalid-content-type-endpoints
Sep 1, 2026
Merged

feat: Add --allow-invalid-content-type-endpoint option to validate-json#932
DannyvdSluijs merged 3 commits into
jsonrainbow:mainfrom
zoliszabo:feature/env-for-invalid-content-type-endpoints

Conversation

@zoliszabo

Copy link
Copy Markdown
Contributor

Description

The validate-json CLI now accepts a repeatable --allow-invalid-content-type-endpoint=<url> option. Each URL prefix is registered on the UriRetriever via the existing addInvalidContentTypeEndpoint() method, bypassing the schema media type check for schemas fetched from that host.

Related Issue

N/A

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation update
  • Code refactoring
  • Other (please describe):

Checklist

  • I have read the CONTRIBUTING guidelines
  • My code follows the code style of this project
  • I have added tests that prove my fix is effective or that my feature works
  • All new and existing tests pass
  • I have updated the documentation accordingly
  • My changes generate no new warnings

Additional Notes

Example use case:

WordPress's theme.json uses https://schemas.wp.org/trunk/theme.json as its JSON schema (docs here: https://developer.wordpress.org/block-editor/reference-guides/theme-json-reference/theme-json-living/). That URL redirects to https://raw.githubusercontent.com/WordPress/gutenberg/trunk/schemas/json/theme.json, which serves Content-Type: text/plain; charset=utf-8, so running

vendor/bin/validate-json theme.json https://schemas.wp.org/trunk/theme.json

fails with InvalidSchemaMediaTypeException.

With the included changes, passing --allow-invalid-content-type-endpoint=https://schemas.wp.org/ whitelists the requested host and lets the validation run.

vendor/bin/validate-json theme.json https://schemas.wp.org/trunk/theme.json --allow-invalid-content-type-endpoint=https://schemas.wp.org/

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot wasn't able to review any files in this pull request.


💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@DannyvdSluijs DannyvdSluijs left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the addition. This is a good improvement, going through the changes I've made some comments to fix some small issues being introduced.
Can you take a look?

Comment thread bin/validate-json Outdated
Comment thread bin/validate-json
@zoliszabo

Copy link
Copy Markdown
Contributor Author

@DannyvdSluijs Thanks for the review. I pushed new commits fixing the highlighted issues.

The validate-json CLI now accepts a repeatable `--allow-invalid-content-type-endpoint=<url>` option.
Each URL prefix is registered on the UriRetriever via the existing `addInvalidContentTypeEndpoint()` API, bypassing the schema media type check for schemas fetched from that host.

WordPress's `theme.json` uses `https://schemas.wp.org/trunk/theme.json` as its JSON schema (docs here: https://developer.wordpress.org/block-editor/reference-guides/theme-json-reference/theme-json-living/).
That URL redirects to `https://raw.githubusercontent.com/WordPress/gutenberg/trunk/schemas/json/theme.json`, which serves `Content-Type: text/plain; charset=utf-8`, so running `vendor/bin/validate-json theme.json https://schemas.wp.org/trunk/theme.json` failed with `InvalidSchemaMediaTypeException`.
With the included changes, passing `--allow-invalid-content-type-endpoint=https://schemas.wp.org/` whitelists the requested host and lets the validation run.
Accept the value in both --option=value and --option value forms. Exit with a non-zero code when the value is missing instead of silently ignoring an empty value. Add CLI coverage for the option.
@DannyvdSluijs
DannyvdSluijs force-pushed the feature/env-for-invalid-content-type-endpoints branch from fa0d555 to 281a878 Compare September 1, 2026 17:26
@DannyvdSluijs
DannyvdSluijs merged commit d0426c5 into jsonrainbow:main Sep 1, 2026
18 checks passed
DannyvdSluijs added a commit that referenced this pull request Sep 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants